Data Cloud stands as Salesforce's fastest-growing product at present. It serves to consolidate all customer data into a singular repository, harmonizing its presentation, and organizing customer profiles in alignment with the company's strategic objectives.

Our research team found that the majority of customers wanted one unified Data Cloud across their various Salesforce orgs. The current model forced users to log in and out of separate orgs, reconcile data manually, and operate without a single source of truth.

The core opportunity: enable bi-directional connections between Salesforce orgs and Data Cloud — so harmonized data can flow back to where it's needed, eliminating the need for separate Data Cloud orgs entirely.

This project spans two distinct Salesforce environments and four different user types: the Data Cloud admin and general user operating within the Data Cloud org, and the Salesforce org admin and general user in connected orgs like Sales Cloud and Service Cloud. Each group has different levels of technical fluency, different goals, and different mental models for what "data" means in their day-to-day work.

The discussion for Data Cloud One began with many cross-functional meetings introducing what this feature needed to do across all Salesforce orgs. My product managers brought me the requirements and we dug into frontline issues together before any design work began.

I grounded ideation in three "How Might We" statements to guide design across all 15 flows delivered by end of 2024:

• How can we teach users about the new Remote Data Cloud concept?
• How can we simplify the connection creation process?
• How can we keep users informed about their connections for better data management?

For each flow, after requirements were introduced on day 1, I drafted flowcharts to serve as the blueprint for the official screen-by-screen experience. Here are the two iterations of flowcharts for one example flow — a Data Cloud Admin setting up a Companion Connection:

Once the flowcharts were approved, I moved into lo-fi wireframes — reviewed and iterated with the PM and engineers around days 2 and 3. From there, designs escalated to mid-fi for leadership review by day 3, and into mid/hi-fi by day 5. Continuing with the Companion Connection example:

After completing the lo-fi and mid-fi designs, I recruited internal and external users for research interviews to validate our direction and surface pain points before finalizing the hi-fi. The research surfaced clear patterns around how customers were experiencing — and struggling with — the flows we designed.

After all flows were complete, I recruited internal and external users to test the main end-to-end flows. I collected all feedback in FigJam — first organized by person, then color-coded by positive and negative sentiment — and synthesized it into themes.

The approved design was implemented into one of Data Cloud's newest breakthrough features: Data Cloud One. The final Companion Connection flow incorporated changes to terminology, step-by-step guidance, multiple entry points for creating new connections, and clearer status indicators throughout.

Below is a walkthrough of the finalized "Creating a Companion Connection" flow:

Salesforce Data 360 is a suite of data products that helps businesses bring together all their customer data — from CRMs, marketing tools, support systems, and more — into one place. Think of it as a single source of truth for everything you know about your customers, built to power smarter decisions and more personalized experiences across Salesforce.

Within Data 360, Identity Resolution is the feature that figures out when multiple records are actually the same person. For example, "Jane Smith" in your CRM and "j.smith@company.com" in your email tool might be the same Jane — Identity Resolution matches them and merges them into one unified profile. The cleaner the merge, the more accurate the customer picture your teams work from.

Once Identity Resolution runs and produces unified profiles, users face a critical gap: there's no way to actually see how well it worked. Did the merge improve data quality? Are profiles being resolved at the right rate? Is the data getting better or worse over time? These questions had no answers inside the product — users were left guessing.

For Data Cloud Admins and Data Systems Architects, this wasn't just frustrating — it was a trust problem. They'd invested significant time configuring matching rules and reconciliation settings, but had no feedback loop to know if that effort was paying off. Without visibility into outcomes, optimizing the system was nearly impossible. You can't improve what you can't see.

The primary user for Identity Resolution is the Data Systems Architect — a technically fluent role that sits at the intersection of data engineering and business strategy. They're responsible for designing and maintaining the data infrastructure that the rest of the organization depends on.

Across the Ease of Use initiative, the UX research team conducted broad discovery research spanning the entire Data 360 platform. The findings painted a consistent picture: users were capable and motivated, but the product was putting up unnecessary walls. Identity Resolution surfaced some of the most acute friction points in the entire suite.

With research in hand, the Ease of Use team came together for an onsite. The goal: align on a shared design philosophy before anyone started ideating. Two key frameworks emerged that would guide every designer's work going forward.

With the North Star defined, I began concepting what the outcomes view could actually look like. The focus was on three core elements users needed: data quality indicators, visual resolution metrics, and trends over time — all surfaced in a way that was scannable and actionable, not overwhelming.

Once the designs were in a strong place, my PM and I prepared a presentation for product leadership. We framed the work around the user gap — the fact that Identity Resolution was producing outcomes that no one could actually see — and showed how our North Star would address it.

The pitch: start surfacing unified profile quality and analysis as a first-class experience within Data 360, with clear resolution metrics, data quality indicators, and trend visualizations. Rather than proposing a full build-out, we scoped it as something that could be introduced incrementally across future releases.

Below is a walkthrough of the final design prototype — showing the unified profile quality and analysis experience we proposed and got approved for Data 360's release roadmap.

When Data Cloud unifies a customer record, it can aggregate hundreds of attributes from dozens of source systems — purchase history, support tickets, email engagement, web behavior, demographic data, and more. In theory, this creates an incredibly rich picture of each customer.

In practice, all of that data was presented in a single, undifferentiated list. My team owned the Customer Profile Explorer — the UI surface where Data Cloud users view and investigate individual unified customer records.

The existing profile view presented every attribute in a flat list — hundreds of fields with no hierarchy or context. Users investigating a customer record had to scroll endlessly and held no mental model for where important information lived.

The goal: design an analysis experience that surfaces what matters without hiding what's needed.

Before redesigning anything, I needed to know what users were actually looking for when they opened a profile — and why. I ran a 2-week diary study with 6 power users across customer success, marketing, and sales ops roles, asking them to log every profile visit with a brief note on their goal.

The finding was striking: despite hundreds of available fields, the actual lookup behavior was highly concentrated. Almost every session was driven by one of the same 6 questions.

The diary study revealed a clear tension: most users needed fast access to a small set of fields, but a subset of power users (data engineers, analysts) needed to access the full attribute set regularly for deep investigation. A design that served only one group would fail the other.

The design challenge became: how do you build a single interface that feels fast and scannable for the majority, while remaining complete and navigable for the few who need everything?

I explored 3 structural approaches: a tabbed interface (attributes by category), a search-first model (find-by-typing), and a progressive disclosure model (summary header + full explorer beneath). I prototyped each at lo-fi and presented them in a team design critique before testing externally.

The progressive disclosure model won internally and in early customer feedback — it was the only approach that felt fast for quick lookups without sacrificing depth for power users.

Our primary success metric was simple: can users find a specific attribute faster? I built a hi-fi prototype of the progressive disclosure model and ran moderated usability testing (n=6) with the same profiles used in the diary study as test stimuli.

The results exceeded expectations: median time-to-find dropped from 40 seconds to 8 seconds — a 5× improvement. All 6 participants also correctly used the pinning mechanic without instruction.

The final design introduces a smart summary header — the 6 most universally accessed attribute groups surfaced above the fold in scannable cards. Below, a full attribute explorer with category grouping and inline search handles the power-user depth case. A pin icon on any attribute lets users customize their summary header.

Currently in Beta with a cohort of early-access customers. Full outcome metrics — task success rate, time-to-find, session engagement — will be added post-GA. The project is on track to ship to GA in Q2 2025.

Beta is the beginning. Here's what I'd carry forward — and the highest-priority follow-on investments.

Salesforce Data Cloud is a complex, multi-capability platform used by four distinct user personas: Data Engineers who build pipelines, Marketers who build segments and campaigns, Admins who configure the platform, and Analysts who investigate data and build reports.

My team owned the Application Home — the first screen every user sees when they log in. At the time I picked this project up, it was a static "recents" list that hadn't been intentionally designed. It was the product's first impression, and it was making a bad one.

Data Cloud's home page was a static list of recent items — identical for every user, every role, every day. There was no guidance for new users, no prioritization for returning ones, and no signal about what needed attention.

With a rapidly growing user base spanning 4 distinct roles with nearly zero task overlap, we needed a home that actually understood who was looking at it.

Before running any interviews, I partnered with our researcher and the data analytics team to pull FullStory session recordings and behavioral data across 400+ sessions. We specifically looked for: what users did on the home page (or didn't), how long they spent there, and what their first navigation action was.

This gave us a quantitative baseline before we introduced any interview bias. Then we ran 10 in-depth interviews segmented by role — separately mapping new user onboarding behavior and returning user daily patterns.

The research revealed two distinct problems that the home page needed to solve simultaneously: a first-session wayfinding problem (new users had no idea where to start) and a returning-user efficiency problem (experienced users wanted to jump straight to what needed attention).

I facilitated a design principles session with the PM and tech lead to formally name these as two co-equal design targets — which then became the criteria against which we evaluated every concept direction.

I explored 3 structural directions: a fully personalized home (user-configurable modules), a role-aware home (system-assigned layout based on assigned role), and a universal home with a priority zone + role-specific quick actions. Each had meaningful trade-offs between implementation complexity and user value.

Customer concept tests (n=8, 2 per role) pointed clearly to the third direction — users didn't want to configure anything, but they did want relevant quick actions and alerts surfaced without manual setup.

I built two prototype variants — one showing the new user onboarding state, one showing the returning user daily view — and ran role-segmented usability testing (n=8, 2 per role). The key test questions: does the onboarding state help new users find their first meaningful action? Does the daily view surface the right priorities?

Both scenarios passed the primary success criteria. The one significant finding: the alert zone was initially dismissed as decorative. We increased visual weight and added an unread count badge — post-iteration, all participants engaged with it.

The final design introduces a three-zone layout: a priority zone at the top (alerts, stale segments, items requiring attention), a role-specific quick-action row below it, and a recent activity feed at the bottom. New users see an onboarding checklist in place of the priority zone until they've completed initial setup.

Designs completed and handed off to engineering. GA target Q2 2025. Success metrics: home page engagement rate, time-to-first-action for new users, and 30-day retention by role. Full outcome data will be added post-launch.

The role-aware home is v1. Here's what I'd carry forward — and the highest-priority evolutions once we have post-launch usage data.

Data 360 is Salesforce's customer data platform — bringing together data ingestion, transformation, identity resolution, and activation into a unified system. Its breadth is its strength: a single platform that connects every touchpoint in the customer data lifecycle.

But that breadth came with a cost. Setting up Data 360 meant navigating each product space in sequence: Data Streams for ingestion, Data Mapping for transformation, Identity Resolution for merging customer records, and more — each with its own UI, its own configuration logic, and no awareness of the others. Users had to understand the full architecture before they could get started.

This project was part of a larger, cross-functional initiative across the Data 360 org — involving multiple PMs, Designers, and Engineers — focused on a single question: what if setup started with a business outcome instead of a product space?

The old setup model was siloed by design. Each product space was a separate destination — users had to navigate to Data Streams, configure ingestion, then navigate to Data Mapping, configure transformations, then navigate to Identity Resolution, configure merge rules — in the right order, with no unified progress view, no cross-space guidance, and no indication of how one configuration would affect the next.

The result: setup was a maze that only people who already knew the system could navigate. New customers arrived with a business goal in mind — "I want to unify my retail and e-commerce customers so I can personalize their experience" — but the product asked them to think in technical primitives: which data streams, which mapping rules, which IR thresholds. Without a clear path forward, many customers stalled in setup or leaned heavily on Professional Services to get started.

The root issue wasn't missing features — every product space had what it needed. The gap was at the seams: no connective layer that could take a user's intended outcome and turn it into a coherent setup path across the platform.

The cross-functional team ran discovery sessions with a range of stakeholders: new customers working through initial setup, experienced admins who had been through it before, and Customer Success Managers who coached customers through the process. We also reviewed support tickets, onboarding call recordings, and PS engagement patterns to understand where the biggest drop-off points were.

A consistent pattern emerged: customers reasoned about their data in terms of business outcomes — the segments they wanted to create, the journeys they wanted to activate, the quality thresholds their downstream teams needed — not in terms of product spaces. The platform's structure was invisible to them at the start. What they needed was a way to express their goal and have the system translate it into a configuration path.

The initiative aligned on a clear direction: replace the siloed, product-space-first model with an outcome-based setup flow. Instead of navigating through Data Streams, then Data Mapping, then IR independently, users would start by selecting a template or business outcome — "Unify retail and e-commerce customers," "Build a complete view of healthcare patients," "Consolidate B2B account hierarchy" — and Data 360 would generate the full setup path for them.

The design principle was simple: the system should know what a good setup looks like for a given outcome — not expect users to figure that out from scratch. And beyond just telling users what to configure, the new model would explain why — surfacing the reasoning behind each agentic recommendation so users could understand, trust, and customize the generated path.

The most consequential design challenge wasn't the template library or the progress view — it was the agentic recommendation layer: how should the system communicate what it's recommending, why, and what the user can do about it?

We explored a spectrum from "silent automation" (the system just configures everything without explanation) to "full chat" (a conversational agent that walks through each step). Neither extreme worked. Silent automation felt black-box and eroded trust. Full chat created friction and slowed down users who already knew what they wanted. The right model was structured transparency: recommendations presented inline, with clear rationale, in a format users could scan, accept, or override without needing to engage in dialogue.

Concept validation sessions were run with enterprise Data Cloud Admins across industries — presenting hi-fi prototypes of the outcome-based setup flow and testing against three core scenarios:

• Template discovery: Can a new admin find a template that maps to their business goal, and understand what it will configure before committing?
• Agentic recommendations: When the system explains why a configuration step is recommended, does the user understand and trust the reasoning — or does it feel opaque?
• Customization: When a user wants to deviate from the generated path, can they identify the right step to modify and understand the downstream impact?

Early signals: the outcome template entry point tested strongly — users immediately understood the intent and selected templates confidently. The inline "why" rationale on agentic recommendations was well-received, particularly among users who had previously felt setup was a black box. The unified progress view needed more work — users wanted clearer signals for what was "blocking" vs. "optional" across the path.

The current design centers on a single Outcome Setup screen that replaces the fragmented, product-space-by-product-space flow. It's organized around three zones:

Outcome selection: a searchable template library organized by industry and use case. Each template previews which product spaces will be configured and what the expected data output looks like — so users understand the scope before they start.

Agentic configuration path: the generated setup sequence, displayed as a vertical flow of steps spanning all relevant product spaces. Each step includes an agentic recommendation — a concise, plain-language explanation of why this configuration is recommended for the selected outcome — alongside accept, customize, and skip actions.

Progress tracker: a persistent sidebar showing overall setup status across all product spaces — with clear blocking vs. optional indicators, and a completion estimate so users always know where they stand.

This is an ongoing, cross-functional initiative across the Data 360 org. Currently iterating on the unified progress tracker, the agentic recommendation format, and the template library IA. Full case study and outcome metrics will be published when the initiative ships.

Still in progress — but these are the learnings already shaping the work, and what this foundation will unlock as the initiative matures.